wafer.space Community - Using gf180mcu_ocd

Creating a thread to avoid spamming #general

14:18

And I also can't creae issues on the gf180_ocd_io repo because issues are disabled on it.

Actually, I think there is no reason. I simply wanted to do it like the SCL library where you can just select a different one and all the views will point to that one instead. But the PAD library is a bit more complicated and just selecting a different one does not work that well.

Well having the PAD_CELL_LIBRARY is nice. But ATM some of the config seem to be set in the base file based on replacing $PAD_CELL_LIBRARY and some config is set by loading the subdirectory tcl file. And I think putting it all in the subdir file (possibly still using $PAD_CELL_LIBRARY so you can easily create new config for new IO lib by just copying and patching the little things needed.

1

14:28

Now I'm faced with the much more annoying issue that OpenROAD is segfaulting on me during GlobalRouting

1

Found what OR didn't like

1

292 Magic DRC errors found.
47 LVS errors found.

18:32

The DRC errors are in the corner cells and looking at the upstream repo, I think @Tim Edwards already fixed them a few hours ago.

18:32

The LVS errors look related to the analog pads having DVSS shorted to ASIG5V ... (edited)

1

@tnt: I've been chasing those errors all day long. Hopefully it should be resolved by tomorrow.

@Tim Edwards DRC or also the LVS one ?

The DRC one. I should have time to look at the LVS issue but I was previously unaware of it. The DRC issue has been bugging me for a while; I just needed to find some time to work on it.

1

Ok. I'll just wait for the DRC one and keep digging on the LVS one, see if I can find what's the cause since it could very well be something on my side that I screwed up ...

@Tim Edwards BTW, did you adapt all the cells including in_s and in_c ? Just to make sure I can also use those

Yes. All digital cells are 3.3V compatible.

1

@tnt: The LVS issue is due to a wayward "DVSS" label that got lost and wandered off and stuck itself to the ASIG5V pad.

I finally found the source of the label, hiding in the LEF file, under the sofa cushions.

Yes, I saw that in the LEF already, I was about to update the issue on github

20:47

Still have some other LVS issue but that'll have to wait a bit.

I have confirmed that fixing the LEF caused the virtual short in the magic view to disappear. It has been pushed.

1

Ok, yeah, remaining LVS is because one net gets extracted as \IO_CORNER_NORTH_WEST_INST.DVSS_RING_uq0 and in the netlist it's \IO_CORNER_NORTH_WEST_INST.DVSS_RING and that causes port mismatch.

21:49

manually fixing that up and running netgen on the result checks out just fine.

If that's a top-level port then you can avoid the unique name by doing extract unique notopports, which was how I got the SRAM to pass LVS.

Yeah, although technically they should be connected internally and not rely on any external connections.

21:54

if I use that option, it wouldn't check if they are connected or not.

21:55

I mean, if all the DVSS nodes were not connected somewhow, it wouldn't spot it.

One way to get around it is just to copy enough of the connection between them inside the top level cell that magic sees that they are connected within the top level. Magic does extraction on each individual cell without looking at what's in subcells that might be connecting things together. Modifying that behavior is probably a lot of work.

1

tnt

Now I'm faced with the much more annoying issue that OpenROAD is segfaulting on me during GlobalRouting

Please do report segfaults upstream - OpenROAD should never segfault.

21154 KLayout DRC errors found. @Tim Edwards

@tnt : I assume those errors are coming from the I/O pads? Can you send me the layout and DRC results? I made many small changes to the I/O layouts, but they are still the same pads apart from swapping in a level shifter circuit in front of each digital pin. However, I read in the I/O GDS and regenerated it from magic, so a single missing output layer or incorrect rule could have a massive effect.

Lots of them are more due to marker layers causing different rules to apply.

Presence or absence of marker layers? Did I manage to drop some ESD marker mask?

Absence. Of ESD and Latchup. And then some Resistor marker layer added instead.

14:44

Let me create a reproducible.

Okay. I'll need to regenerate them with mask hints for the marker layers. I don't think it's going to be a huge effort.

14:45

This is the "dirty" part of "quick & dirty".

klayout -b -zz -r ${PDK_ROOT}/gf180mcuD/libs.tech/klayout/tech/drc/gf180mcu.drc -rd input=/mnt/pdk/OL2/pdk_root/gf180mcuD/libs.ref/gf180mcu_ocd_io/gds/gf180mcu_ocd_io.gds -rd report=drc.klayout.lyrdb -rd feol=True -rd beol=True -rd conn_drc=True -rd wedge=True -rd run_mode=deep -rd thr=16 -rd topcell=gf180mcu_ocd_io__bi_24t

1

14:49

this runs the DRC on only gf180mcu_ocd_io__bi_24t and will show the errors.

14:49

I mean obviously you need to check all the cells, but that's a good start

14:49

And runs much faster than a full chip DRC

@tnt : Where are you getting the file gf180mcu.drc from? I don't have that in my PDK.

@Tim Edwards Ah, from https://github.com/wafer-space/gf180mcu

15:42

I think it's just a top level calling all the rules deck. Probably on @Leo Moser (mole99) 's growing list of stuff to upstream

Exactly

That file belongs in https://github.com/fossi-foundation/globalfoundries-pdk-libs-gf180mcu_fd_pv

GitHub - fossi-foundation/globalfoundries-pdk-libs-gf180mcu_fd_pv

Contribute to fossi-foundation/globalfoundries-pdk-libs-gf180mcu_fd_pv development by creating an account on GitHub.

1

First I need to merge: https://github.com/wafer-space/gf180mcu/pull/1 and ensure there aren't any regressions.

Is that file written in ~~rust~~ ruby? I'm getting ERROR: Can't run macro (no interpreter) but I think I don't have ~~rust~~ ruby enabled in my version of klayout. (edited)

It's written in ruby, perhaps that is missing?

I meant ruby, sorry. I thought rust was wrong, somehow.

All klayout drc are written in ruby AFAIK

15:57

I can run drc for each cell and post results if that's easier but I thought it'd be better if you could validate changes yourself

Posting results might be quicker because I'm going to have to recompile klayout with ruby support. But I did a layer-by-layer comparison between an original 5V I/O cell and my modified one, and I think I understand where I'm missing layers. Some of my generated layers (DUALGATE, for example) are not the same size as the original but are probably still valid. The main issue seems to be the missing "latchup" and "ESD" marker layers. Both are just two rectangular areas under the pad, and easy to add with mask hints. There is another issue with all FETs being marked as 5V due to the fact that the I/O library was created before I modified the handling of 5V/6V cells, but that's easy enough to correct and probably doesn't make a difference anyway.

Arf, sorry for dissapearing ... went to grab a drink, knocked something over and spent the last 30 min cleaning up my mess

16:40

Running DRC now.

16:47

drc.tar.bz2

477.98 KB

16:47

@Tim Edwards

1

More work than I was expecting but shouldn't be too big of an issue.

1

BTW, if there is anything I can do to help, I'd be happy to

I may need to you run more klayout DRC checks. But I need to get some updates pushed, first. I have worked through most of the main errors already. Fortunately the highest count of errors was in the array contact spacing, which was easy to fix (although it exposed a way to get around magic's generation of wider-spaced 4x4-and-up arrays, which is to stack 4 or more 1xN contact arrays next to each other, which then magic no longer sees as a single "large array").

1

@tnt : All right. I think I have a good handle on all the issues. I will push everything to the repository along with updates to open_pdks and everything should be ready to retest in the morning. I may have missed one or two things but nothing looks like it can't be dealt with pretty easily. I do have to rethink the way I handle generating PPLUS and NPLUS around tap diffusion that is too close to an nwell edge, but I think I have methods now that will work right that weren't available when I originally wrote the GF180MCU tech file. I haven't tested them yet; instead I just made sure that all tap diffusion is well away from nwell edges. It seemed like everything in the I/O library was just slightly closer than the limit that triggers the extra overlap (0.43um).

@Tim Edwards - If you have docker installed you can get a docker container with the precheck with all the deps and PDK and everything.

@tnt : I have updated the PDK and the I/O library. I don't know if I managed to get everything, but it should be a lot cleaner than before.

@Tim Edwards Indeed, it seems much cleaner now